fix(server): bound editor discovery and optimize Windows diagnostics#3874
fix(server): bound editor discovery and optimize Windows diagnostics#3874SivanTechDev wants to merge 2 commits into
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
ApprovabilityVerdict: Approved Performance and robustness improvements with defensive patterns: adds timeouts with safe fallbacks to editor discovery (prevents blocking) and optimizes Windows diagnostics queries. Changes are well-tested and limited in scope. You can customize Macroscope's approvability policy. Learn more. |
|
Closing to replace commits that contained unintended personal author metadata. No replacement PR will be opened at this time. |
What Changed
server.getConfigto 500 ms.Why
Fixes #3610.
On the affected Windows machine,
server.getConfigcould remain blocked while resolving optional external editors. When the request was interrupted, the client treated the local environment as disconnected, so project history and provider configuration did not load.Editor discovery is optional and should not block the rest of the server configuration. The 500 ms limit preserves detected editor results when discovery completes promptly. If discovery times out, the server returns an empty editor list rather than advertising an unverified launcher, while allowing the rest of the configuration to load.
Windows process diagnostics also queried
Win32_PerfFormattedData_PerfProc_Processonce for every process. On the affected machine, that N+1 query shape exceeded the existing timeout. Loading both CIM classes once and joining them by process ID completed in about 866 ms.The Windows timeout is increased to 5 seconds to leave reasonable headroom for slower hosts. The existing 1-second timeout remains unchanged for POSIX diagnostics.
Validation
server.getConfigtimeout regression test passed.Checklist
Note
Medium Risk
Touches hot paths (
server.getConfigand Windows diagnostics) that affect connection UX and process listing; behavior changes are bounded by timeouts and fallbacks rather than altering auth or data persistence.Overview
Fixes local environments appearing disconnected when optional work blocked
server.getConfigon slow Windows hosts.server.getConfignow caps editor discovery at 500 ms and returns an emptyavailableEditorslist on timeout so the rest of config (environment, auth, providers, etc.) can finish without waiting onresolveAvailableEditors.Windows process diagnostics no longer run N+1
Get-CimInstanceperf queries per process. The PowerShell script loadsWin32_PerfFormattedData_PerfProc_Processonce into a hashtable, loadsWin32_Processonce, and joins by process ID. Process query timeouts are per-platform: POSIX stays at 1 s, Windows rises to 5 s via atimeoutMillisparameter onrunProcess.Regression tests cover the Windows bulk CIM script shape and that
server.getConfigcompletes when editor discovery never resolves.Reviewed by Cursor Bugbot for commit fb9096e. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Bound editor discovery to 500ms timeout and optimize Windows process diagnostics
serverGetConfigin ws.ts now times out editor discovery after 500ms and returns an emptyavailableEditorsarray instead of blocking indefinitely.Win32_PerfFormattedData_PerfProc_Processonce and correlate results in memory via a$perfByIdhashtable, replacing per-process CIM queries.serverGetConfigcallers will now receiveavailableEditors: []if discovery does not complete within 500ms.Macroscope summarized fb9096e.